Date: Wed, 1 Jun 94 04:30:01 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #106 To: tcp-group-digest TCP-Group Digest Wed, 1 Jun 94 Volume 94 : Issue 106 Today's Topics: Digital Communitations? ... When?? Gracilis Linux SCC drivers nos-bbs mail address hosed? (5 msgs) subscribe aadamson@symantec.com TCP-Group Digest V94 #103 (3 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 31 May 94 22:40:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Digital Communitations? ... When?? To: tcp-group@ucsd.edu Cc: eb3aod@ALBINYANA.ETSE.URV.ES e> I read a lot of time, papers, RFC, about "Packet Radio" and something the e> author says "digital communication" when i think this is a wrong sentence. e> We do (the om's) "Packet Radio". This kind of communication is analog not e> digital so we use a modem ... e> Am i wrong about this?? Why does a lot of people say e> "Digical Communication" when refers the "Packet RAdio"?? This has the makings of a "religious" dispute, but my opinion is that the content of the information is what is being described. Packet radio, like RTTY or even morse code, transmits information which is itself digital in nature. All real methods of communication are analog, and always will be. Even computers are actually analog devices in a physical sense, storing voltages and maintaining circuits in either a charged or discharged state. Such things in the analog world represent ones and zeroes, but are not themselves ones and zeroes. -- Mike ------------------------------ Date: Tue, 31 May 1994 08:54:41 -0400 (EDT) From: "Barry McLarnon" Subject: Gracilis To: tcp-group@ucsd.edu > > Dunno where you've been, buit there are currently Linux drivers for SCC cards, > > the Ottawa PI2 card, and I'm working on PackeTwin drivers. > > > > Where are they available for FTP? Thanks. The PI2 Linux driver is available for anonymous FTP from the infamous :-) hydra.carleton.ca site. This driver supports the DMA capabilities of the PI2 - it's not a generic SCC driver. I understand that the latter exists, but I don't know where it can be found. For more info on the PI2, send mail (any subject/text) to: pi-info@hydra.carleton.ca Barry -- Barry McLarnon VE3JF/VA3TCP | Internet: barry@dgbt.doc.ca Communications Research Center | AMPRnet: barry@va3tcp.ampr.org Ottawa, Ontario, Canada | FreeNet: aa187@freenet.carleton.ca ------------------------------ Date: Tue, 31 May 94 22:51:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: Linux SCC drivers To: tcp-group@UCSD.EDU Cc: iiitac@pyr.swan.ac.uk AC> The current Linux kernel drivers are for the PI/PI2 AC> card and for a standard AC> TNC. There are (as yet) no generic SCC drivers for the Linux kernel AX.25 AC> although they shouldn't be too hard to write, and AC> generic 8530 support will AC> be useful for synchronous I/O cards as well as Amateur Radio. I have a file of something that claims to be a beta of a generic SCC driver for the Linux kernel, written by PE1NNZ. The "INSTALL" notes say that it is implemneted as part of the kernel and was tested with several different software packages, including WAMPES and KA9Q Linux ports. However, the author says that he only tested it with the OptoSCC hardware. I seem to recall getting the file from UCSD.EDU originally, so I assume it is available there somewhere. The author gives his information as: Guido ten Dolle Veltackerstraat 5 5087 AG Diessen The Netherlands Phone 04254-1653 S&F - PE1NNZ@PI8HWB.#NWB.NLD.EU SMTP - pe1nnz@pi8hvh.ampr.org The file name of what I have here is sccdrv12.tar.Z, dated 93-July-24. -- Mike ------------------------------ Date: Tue, 31 May 1994 07:54:33 CST6 From: "Chris Cox W0/G4JEC" Subject: nos-bbs mail address hosed? To: Lyndon Nerenberg > and I would disagree with the latter as a matter of principal, since > you're *very* unlikely to find a wildcard MX for a top level domain. What about the old controversy with North American PBBS-destined mail being sent from the Internet being routed to Namibia? -- Chris Chris Cox W0/G4JEC chrisc@Central.NMMC.Mn.Org Network Analyst NIC Handle: CC345 North Memorial Medical Centre Tel: (612) 520-7321 3300 Oakdale Avenue North Fax: (612) 520-5237 Robbinsdale, MN 55422 Europeans consider 100 miles a long way. Americans consider 100 years a long time. ------------------------------ Date: Tue, 31 May 1994 08:26:17 -0700 From: brian@cyberpunk.ucsd.edu (Brian Kantor) Subject: nos-bbs mail address hosed? To: tcp-group@UCSD.EDU In article you write: >> If there is no MX record at all, then DNS queries will be sent for MX >> of"hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for an A >> record is made. This is incorrect and should not be done. > > * MX for hydra.carleton.ca > * A for hydra.carleton.ca And that's as far as it goes. The lookup should NOT continue to > * MX for *.carleton.ca > * MX for *.ca The actual process is: 1. look for an MX record for the domain in the mail address 2. if you got an MX record, choose the lowest numbered one. If none, use the domain in the mail address to generate a single 0-preference MX record 3. look for an A record for the host obtained in step 2 above. (if none, that's a configuration error and the mail is undeliverable) 4. attempt to deliver the mail to that host 5. if delivery cannot be completed due to non-permanent errors, repeat steps 3-on until delivery is achieved using the next lowest MX. If delivery cannot be achieved by the time all MX records are exhausted, queue the mail and retry later. There is a more complete discussion of this in various RFCs; for a start, see RFC1123. - Brian ------------------------------ Date: Tue, 31 May 1994 09:50:01 -0700 (PDT) From: Lyndon Nerenberg Subject: nos-bbs mail address hosed? To: Chris Cox W0/G4JEC > > and I would disagree with the latter as a matter of principal, since > > you're *very* unlikely to find a wildcard MX for a top level domain. > What about the old controversy with North American PBBS-destined mail > being sent from the Internet being routed to Namibia? A perfect example of *why* you're unlikely to see wildcard MX's for country level domains. --lyndon ------------------------------ Date: Tue, 31 May 94 13:23:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: nos-bbs mail address hosed? To: tcp-group@UCSD.EDU Cc: lyndon@freenet.unbc.edu > If there is no MX record at all, then DNS queries will be sent for MX > of "hydra.carleton.ca", "*.carleton.ca", and "*.ca" before a request for > an A record is made. LN> Is this the case? We're crossing boundaries between DNS and MTA LN> implementation here, but it seems to me that any MTA that would query LN> *.ca MX's when looking for hydra.carleton.ca is broken. A reasonable LN> search tree would be: LN> * MX for hydra.carleton.ca LN> * A for hydra.carleton.ca LN> * MX for *.carleton.ca LN> * MX for *.ca LN> and I would disagree with the latter as a matter of principal, since LN> you're *very* unlikely to find a wildcard MX for a top level domain. LN> Much of this depends on how flexible (smart?) your resolver routines are. No, it depends on the top-level domain itself. Obviously, top-level domains such as "ca" are not going to have MX records defined, but a surprisingly large number of other top-level domains do have MX records defined. The most infamous example is Namibia, which has the top-level domain "na". :-) -- Mike ------------------------------ Date: Tue, 31 May 94 23:05:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: nos-bbs mail address hosed? To: tcp-group@ucsd.edu Cc: lyndon@unbc.edu > > and I would disagree with the latter as a matter of principal, since > > you're *very* unlikely to find a wildcard MX for a top level domain. > What about the old controversy with North American PBBS-destined mail > being sent from the Internet being routed to Namibia? LN> A perfect example of *why* you're unlikely to see wildcard MX's for LN> country level domains. > set type=mx > *.na Server: LOCALHOST Address: 127.0.0.1 *.na preference = 10, mail exchanger = grimsel.frcs.alt.za *.na preference = 100, mail exchanger = nuustak.csir.co.ZA -- Mike ------------------------------ Date: Tue, 31 May 94 09:34:47 pst From: "Alan Adamson" Subject: subscribe aadamson@symantec.com To: tcp-digest@ucsd.edu subscribe aadamson@symantec.com ------------------------------ Date: Tue, 31 May 94 09:20:03 -0500 From: sbrown@charon.dseg.ti.com (Steve Brown) Subject: TCP-Group Digest V94 #103 To: jack@victron.nl RSPF = Radio Shortest Path First ********************************************* | Steve Brown, WD5HCY | | | sbrown@charon.dseg.ti.com | Simplicate | | wd5hcy@wd5hcy.ampr.org | and add | | [44.28.0.61] | lightness. | | wd5hcy@kf5mg.#dfw.tx.usa.na | | ********************************************* ------------------------------ Date: Tue, 31 May 1994 11:39:59 -0400 From: goldstein@carafe.tay2.dec.com Subject: TCP-Group Digest V94 #103 To: tcp-group@UCSD.EDU >Maybe a silly question, >but what is RSPF? No silly questions, just silly answers. :-) In a nutshell, RSPF (Radio Shortest Path First) is a protocol for determining the best route within a packet radio network. Like IS_IS and OSPF, it uses the link state approach with a Dijkstra SPF spanning tree. It is specifically written for IP, like OSPF, but has a few special features. It is simpler, so it can be done in ham applications like KA9Q NOS. It doesn't believe in IP "subnets" (Ethernet-like with assumed full connectivity) but instead aggregates neighboring stations into "node groups", and allows "route horizons" so that SPF routing can take place _within_ a node group and not be seen far away. This latter feature has proven hard to implement within NOS code and leads to some difficulties. There are no complete implementations yet out there. Version 2.1 ofthe spec, written (by myself) several years ago, was partially implemented. Version 2.2, which clarifies some things, has not been implemented. fred k1io ------------------------------ Date: Wed, 1 Jun 1994 10:26:28 +1000 From: makinc@hhcs.gov.au (Carl Makin) Subject: TCP-Group Digest V94 #103 To: tcp-group@ucsd.edu At 7:50 PM 30/5/94 -0000, jack@victron.nl wrote: > Maybe a silly question, > but what is RSPF? Really Super but Partly Functional routing protocol. RSPF is an interior routing protocol designed with Amateur Radio networks in mind. Unfortunately there has never been a fully functional port into *NOS. What is in *NOS can be made to work can be made to work if you're very careful. Carl. -- Carl Makin (VK1KCM) "Speaking for myself only!" '+61 6 289 8443' makinc@hhcs.gov.au (Internet) / vk1kcm@vk1kcm.act.aus.oc (Packet Radio) 'The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.' ------------------------------ Date: Tue, 31 May 94 15:56:18 +0100 From: Alan Cox To: tcp-group@ucsd.edu >From: Barry McLarnon >The PI2 Linux driver is available for anonymous FTP from the infamous :-) >hydra.carleton.ca site. This driver supports the DMA capabilities of the >PI2 - it's not a generic SCC driver. I understand that the latter exists, >but I don't know where it can be found. The current Linux kernel drivers are for the PI/PI2 card and for a standard TNC. There are (as yet) no generic SCC drivers for the Linux kernel AX.25 although they shouldn't be too hard to write, and generic 8530 support will be useful for synchronous I/O cards as well as Amateur Radio. Alan ------------------------------ End of TCP-Group Digest V94 #106 ******************************